To confirm, this change makes it possible to open the page, but the stack traces will still not work (since a file: url can't opt-in to supporting cross-origin requests)?

After this change I get a Java stacktrace in Chrome and source map seems to work even with

• file:// protocol used both for JS and document
• localhost used for JS, file:// protocol used for document
  For uncaught exception the stacktrace looks the same as if and http:// was used for document
  

For caught exceptions that go through logger with exception unwrapping utility the stacktrace for file:// and http:// is slightly different

vs

Note that the code doesn't use GWT's builtin UncaughtExceptionHandler but a custom onerror handler.

Nice - that's pretty much exactly what was failing that caused us to add this to begin with, glad it isn't necessary here.

Correct me if I'm wrong but it looks like there's no stack trace then. What does it look like without the custom error handling code? (I suppose the same without the white text?)

no stack trace then.

yep, but still the dev tools show you all the filenames and line numbers.

What does it look like without the custom error handling

I guess very similar. The custom code is there just to

1. make sure the native JS exception is printed to the console, not the wrapping Java Exception (just saves you some clicks expanding objects in console)
2. work around Avoid calling undefined method in UncaughtExceptionHandler gwt-core#18

Bottom line: for file:// protocol the script didn't start before, now it starts. For http:// protocol nothing changed in this PR.